[レポート] AWS Fargateを活用したマイクロサービスのデプロイ #reinvent #CON315

こんにちは。サービスグループの武田です。

CON315-R - [REPEAT] Deploying Microservices Using AWS Fargate に参加してきましたのでレポートをお届けします。

なお同じセッションに参加した濱田もレポートを書いていますので合わせて参照していただければ。

[レポート]AWS Fargateを利用したマイクロサービスの開発手法 #reinvent

セッション概要

KPMG has built a customer due diligence solution for a high-profile banking client in AWS. This solution is composed of a number of microservices that are deployed to containers using AWS Fargate. In this session, we dive into the details of the solution's architecture. We discuss how the infrastructure and applications are deployed using third-party tools, such as HashiCorp’s Terraform and Jenkins, and we share best practices for running containers in production workloads. We also go into detail on the AWS resources used in the solution, including Amazon DynamoDB, Amazon ECS, AWS Fargate, and Amazon S3, as well as CI/CD and automation. We focus on security to meet banking regulatory requirements. We also discuss how KPMG has configured for canary deployments to ECS and Fargate, how it handles secrets management and encryption, and how it manages service discovery between the microservices using ECS Service Discovery and Amazon Route 53.

アジェンダ

• AWS Fargate入門とユースケース
• AWS Fargateによる複数環境の管理
• KPMGでの開発、デプロイおよび管理のワークロード

セッションメモ

AWS Fargate入門とユースケース

• コンテナサービスについて
  • マネジメント層
    • Amazon ECS, Amazon EKS
  • ホスト層
    • Amazon EC2, AWS Fargate
  • イメージレジストリ層
    • Amazon ECR
• EC2を使用する場合、ECS AgentやDocker Agent、ECS AMIなどを利用しないといけない
• Fargateではよりシンプルになる

• Amazon Elastic Container ServiceのEC2 launch typeを使用するユースケース
  • GPUを使用する場合
  • Windowsのネイティブコンテナを使用する場合
  • スポットフリートを使用する場合
  • C5 for AVX-512などのようなインスタンススペックが重要な場合
  • コンテナの特権が必要な場合
• EC2とFargateのlaunch typeは共存可能

• パーミッションの層を意識する
  • Fargateの場合、クラスタが管理機能の境界となる
  • クラスタのパーミッション
    • クラスタのタスクを誰が見れて起動できるのか
  • アプリケーション（タスク）のパーミッション
    • アプリケーションはどのAWSリソースにアクセスできるのか
  • ハウスキーピングのパーミッション
    • どのような権限をECSに許可するのか
    • ECR image pull
    • CloudWatch Logs pushing
    • ENI creation
    • Register/deregister targets in ELB

AWS Fargateによる複数環境の管理

• 環境ごとにクラスタを管理する必要がある
  • 本番環境
  • 開発環境
  • ベータ環境
  • QA環境（検証環境）
• 環境ごとのネットワーク管理
  • タスクレベル
    • すべてのFargateタスクはVPCネットワークで動作する
    • セキュリティグループとネットワークACLによるネットワークアクセスの制御
    • Public IPのサポート
  • サービスレベル
    • 高可用性のための複数サブネットへのサービスのデプロイ
  • クラスタレベル
    • VPCを分割するか、少なくとも過不足なくIPを割り当てられるだけのCIDRレンジを確保
• 複数環境にわたるマネージドサービスの活用方法
  • コード変更不要なサービス維持
  • サービスレジストリ
    • 予測可能なサービス名
    • healthy IPおよびportの自動的なアップデート
  • オーバーヘッドのないインストールとモニタリング
  • 高信頼性と高スケーラビリティ
  • これらはAmazon Route 53 auto namingによって提供されている

• サービスごとの異なるバージョン
  • 本番環境では1.2、ベータ環境では1.3など
  • ただし、バージョンはサービスごとで、クラスタレベルではない
  • Force New Deploymentを呼ぶことで異なるバージョンにアップデート可能

KPMGでの事例

ここからスピーカーが代わり、KPMGでの導入事例の紹介となりました。

KPMGでは非常にたくさんのプロジェクトおよびプロダクトを開発しており、90％がAWSを利用している。

これまでのCustomer due diligence（CSS）ソリューションでは次のようなアーキテクチャだった。

• SQL Server 2008 on EC2
• Windows Serverにデプロイされた.NETアプリケーション
• サーバーのパッチおよびメンテナンス
• サーバーレベルでのアクセス

新しいCDDのアーキテクチャがこちら。

• EC2はFargateに
• TeamCity+Octopus DeployはDocker+Jenkinsに
• CloudFormationはTerraformに

これらの変更によって協調動作するマイクロサービスとしてアーキテクチャが進化した。

マネージドなコンテナサービスを使用することにってさまざまなメリットが享受できる。

• イミュータブルなデプロイ、サーバー内にログはない！
• AWS Fargateによってクラスタリソースのプロビジョニングが制御できる
• OSのパッチはもう不要
• マシンのスケーリングや設定なども不要に

進化したアーキテクチャのデプロイパイプラインがこちら。

Dockerおよびコンテナの、デプロイとスケーラビリティを容易にするための利点を理解しよう。

• ECSおよびECRとの統合
• JenkinsやBitbucketといった既存のCI/CDツールとの連携
• AWS Fargateの低コスト（TCO）
• 99.99%のSLA
• PCI DSS Level 1, etc.

AWSはKPMGに主に次のようなメリットを与えてくれた。

• コスト削減
• 迅速なデリバリ
• 自動化とDevOps

まとめ

コンテナの入門として全体像の確認、それぞれのサービスの違いから入りました。そこからFargateを使用した場合のセキュリティの考え方や複数環境をどう管理していくかと言った実践的な内容が続きとてもおもしろく聴講できました。後半のKPMGでのEC2からFargateに移行した事例では、単なる載せ替えではなくCI/CDから見直すことによって全体の最適化につながったという話でこれもなるほどと思いながら聞いていました。現在携わっているプロダクトでもFargateは候補に上がっていますので、自分でもトライしていきたいです。

現場からは以上です。